Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9611/000135_owner-urn-ietf _Tue Nov 12 11:42:41 1996.msg

Internet Message Format | 1997-02-19 | 6KB

Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id LAA20848 for urn-ietf-out; Tue, 12 Nov 1996 11:42:41 -0500
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id LAA20840 for <[e-mail]>; Tue, 12 Nov 1996 11:42:32 -0500
Received: from dicsmss1.jrc.it by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA02088  (mail destined for [e-mail]); Tue, 12 Nov 96 11:42:28 -0500
Received: from  jrc.it (elect6.jrc.it) by dicsmss1.jrc.it (4.1/EB-950131-C)
    id AA09612; Tue, 12 Nov 96 17:47:29 +0100
Received: by  jrc.it (5.x/EB-950213-L)
    id AA05351; Tue, 12 Nov 1996 17:41:34 +0100
Date: Tue, 12 Nov 1996 17:41:34 +0100
From: "Dirk.vanGulik" <[e-mail]>
Message-Id: <9611121641.AA05351@ jrc.it>
To: [e-mail], [e-mail],
        [e-mail]
Subject: [URN] Re: Harald's syntax proposals [Somewhat Long] (was I18N does not belong in URNs)
Cc: [e-mail], [e-mail], [e-mail],
        [e-mail], [e-mail], [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
Reply-To: "Dirk.vanGulik" <[e-mail]>
Errors-To: [e-mail]

"Ryan Moats" <[e-mail]> wrote

> On Tue, 12 Nov 1996 16:50:36 +0100, Dirk.vanGulik wrote:
>
> >> To me, the extension (as written) has a couple of holes.  The URN has to have
> >> information about the namespace so that the resolver can resolve the URN
> >> correctly (it took me a while to realize that the proper parsing of option B is
> >> the second ":").  Therefore, having no meaning after the optional "urn:"
> >> doesn't work.
> >
> >I realized this as well; but was (and still am) unsure how to effectuate this;
> >because is implies that the bit between the first to ':' is really limited in
> >encoding. Something which has bothered me in the syntax document. But I have
> >no immediate solution for it.
>
> This is on purpose.  The more you free up the NID encoding, the more you restrict
> potential implementations.
>
> >Well: (Which each char actualy being an octet, etc..)
> >
> >    [<] urn:NS:OPS [>]
> >
> >    NS consists of A..Z, 0..9
> >    OPS consists of A..Z, 0..9, '-', '_' and '.'
> >
> >    The '-','_','.' are kept in reserve for the NS
> >
> >    Whitespace is allowed
> >
> >Would be kind of simple.
>
> Yes, and we may reach something like this eventually (there would
> have to be more characters added to the NSS to support grandfathered
> spaces.  There are just some tradeoffs that we would have to agree upon.

Well the whole point was to 'fudge' this grandfathering; and force (almost)
all of it to use an encoding scheme of some kind; but naturally they _ONLY_
have to know about this encoding when they want to go in- or out- to the
old grandfathered in scheme; and then quite naturally they know what the
secret encoding trick is.

One of the main points I would like to get across is that all this grand-
fathering only matters on the interface between the grandfather and this
new born URN daughter; and exactly on that interface there is all the room
in the world to do say a base64 to XYZ decoding.

> >> >A
> >> >> - The URN syntax doc says that URNs are sequences of ASCII
> >> >>   characters (or some subset thereof)
> >>
> >> This is of course, the simplest.  A minimum of transport encoding would be
> >> involved.  There may be some reserved characters that would be need to be
> >> encoded on a namespace specific basis but those could be done with
> >> %HH encoding.
> >
> >Which would imply namespace specific encapsulation needs; which kind of imposes
> >external NS knowledge on arbritary clients.
>
> Somebody will have to know this anyway.  I'm not saying that all the reserved characters
> have to be in the syntax document (in fact I'm saying they can't).  I'm saying that any
> reserved character should be encoded with %HH, which is slightly different.

Yes; and I woudl really like to argue that there should be NO encoding on this level
at all; the syntax document should be entirely free of it. It might be that in a document
which details how some kind of differnt scheme is grandfathered into a certain NS, one
will have to detail all this; but that is completely outside the URN syntax document
I hope.

As a conclusion; I think we quite agree; but compared to you I would prefer the encoding
to be pushed away further from the URN, and actually not be a part of it; whereas you would
actually allow the URN to consist of arbitrary octets which are encoded with a limited set ?
Or am I wrong again ?

> >> >B
> >> >> - The URN syntax doc says that URNs are sequences of OCTETS,
> >> >>   with no meaning assigned by the URN syntax doc after the
> >> >>   second  ':'
> >>
> >> I've modified the above to point up the ':' character.  This is the "opaque string"
> >> option.  This option would require some transport encoding for 8-bit unclean pipes.
> >> I see presentation as the major trade-off here.  For 8-bit unfriendly schemes,
> >> something like the %HH scheme would be needed.  For others, the %HH scheme
> >> could be mixed with actual glyphs that are representation of that octet (or sequence
> >> of octets) in that presentation scheme.  However, THIS IS ONLY FOR THE
> >> CONVIENCE OF THE PRESENTATION SCHEME, NOT THE USER!!!!
> >> The other difficulty is that reserved characters have to be limited to
> >> a subset of ASCII or there is the possibility for encoding collisions that would require
> >> the syntax doc to specify its own encoding scheme.

> >Somehow not very practical ? IMHO.

> I didn't say it was practical, just tried to state what the tradeoffs are.

Point taken. I was trying to state a point as well :-)

Dw.